CygNet Well Test Components

The CygNet Well Test module is a complex application that integrates several components. The following diagram shows the various components of the module.

Note that this model is only applicable to Host-based configurations. A slightly different model is needed for Device-based configurations. Each component is described below, with a link to more information for each.

See the following subsections for more information:

• Well Test API
• CygNet Well Test Service
• CygNet Setup
• Well Test Configuration Control
• Well Test Configuration XML
• VBScript to Process Well Test Results
• Well Test Record Storage
• Well Test Canvas Screens for HMI

Well Test API

The CygNet Well Test module requires the CygNet.API.WellTest assembly, which is used by the back-end CygNet Well Test Service, the well test configuration XML, the Canvas well test screens, and external systems such as ForeSite. It is located in the CygNet\Bin directory and is automatically version managed by Canvas.

The CygNet.API.WellTest has two helper functions that can be used to retrieve well test records:

• The GetAllWellTests function is supplied with starting and ending timestamps. The well test records are returned in a jagged dictionary object.
• The GetWellTestsForWell function takes in the well facility tags along with timestamps to retrieve the well test records.

See Retrieving Well Test Records for an example of these functions.

CygNet Well Test Service

The CygNet Well Test module requires the CygNet Well Test Service. This Windows service monitors the well test configuration XML stored in the PNT HyperPoint of the Header Queue point for starts and stops, value changes, and then executes the well test commands and actions.

The service requires a Windows service config file, which points to the configuration point containing the well test configuration XML. The CygNet Well Test Service Config File (WellTestServiceConfig.xml) takes the following format:

1
2
3
4
5
<WellTest>
    <ConfigurationPoints>
        <Point>SITENAME.UIS:LONG_ID</Point>
    </ConfigurationPoints>
</WellTest>

The service is installed via CInstall on the host CygNet server and includes an Application Definition File (.app) and Response List File (.rsp) to facilitate version management. The service must be located on the CygNet server and utilizes the CygNet.API.WellTest.

64-bit

The CygNet Well Test Service is 64-bit. Consequently, any custom script actions created that use CygNet COM automation DLLs will require 64-bit versions of those DLLs.

The CxScript64.dll is included in the CygNet Well Test version management process to account for this when using the sample well test scripts.

CygNet Well Test Service Logging

The CygNet Well Test Service creates detailed and useful log entries written to its primary log with a file name similar to CygNetWellTestService0xx.csv.

• Because the service is built in a 64-bit configuration, this log file is written to the C:\Windows\System32 folder.
• Up to 10 log files are created, each with a maximum size of ~10MB and with file names "CygNetWellTestService001.csv" to "CygNetWellTestService010.csv". When log file #010 fills up, it cycles back to log file #001.
• If you do not see these log files being generated, it is likely due to limited permissions for the user account under which the CygNet Well Test Service is running. Running the service under an account with elevated permissions should fix the problem.

Well Test Persistence

The CygNet Well Test Service uses a persistence model to ensure smooth operation of any active well tests should the service shutdown unexpectedly in the middle of a well test operation.

Well Test Configuration XML

When the CygNet Well Test Service starts it reads the Well Test Configuration XML in the PNT HyperPoint script text, which is stored in the HyperPoint script text because it does not change frequently.

Header Queue Points

The Header's PendingWellQueue and ActiveWell/ActionQueue configuration XML for the well in an active well test is stored in separate points' VHS blobs. This allows change synchronization between the CygNet Well Test Service itself, and any external user of the CygNet.API.WellTest, such as the Canvas Well Test Status.can screen.

PendingWellQueue and ActiveWell/ActionQueue are stored as separate points' VHS blobs.

The ActiveWell/ActionQueue settings are managed exclusively by the CygNet Well Test Service and cannot be modified by the CygNet.API.WellTest. This guarantees that the CygNet Well Test Service always knows what the latest configuration is and that nothing has gone behind its back and changed it.

However, because the PendingWellQueue is often changed by users of the Canvas Well Test Status.can screen, additional safeguards are implemented to minimize the chance that the CygNet Well Test Service might be working with a list of pending wells that are not the latest ones stored for that Header. There are still small, but possible, scenarios whereby a user of the Canvas Well Test Status.can screen could make changes, just at the wrong instant, which would not be immediately picked up by the CygNet Well Test Service. But the likelihood of this occurring is unlikely.

Example

In the following example AMANDA_WL is the <ActiveWell> and its <ActionQueue> contains several well test actions to be completed. This data is kept updated as changes occur, but not when the service is triggered for shutdown. When the CygNet Well Test Service is triggered for shutdown, a list of any remaining actions will be written to the <ActionQueue> element of the header point XML. A list of the remaining wells to be tested is written to the <PendingQueue> element (in this case: ESSEN_WL, PELICAN_WL, and VIRGINIA_WL). When the CygNet Well Test Service is triggered to start or restart, the XML configuration will be loaded. The CygNet Well Test Service will then look for the existence of an <ActiveWell>, if one exists, any remaining actions will be loaded into the Action Queue for the Well, and the Action Queue will be restarted (in this case: Test, PointValueCompare, SetPoint, and so on…).

CygNet Setup

The CygNet Well Test module requires a typical CygNet configuration, with defined CygNet facilities, points, UDCs, UIS commands, scheduling commands, etc.

See Configuring CygNet Well Test for more information.

Well Test Configuration Control

The CygNet.API.WellTest.Controls.dll is a plugin control assembly that can be made available for use in Canvas to allow the manual configuration of the well test configuration XML file. This plugin provides a user-friendly method for defining the necessary elements required to execute a well test via a Canvas screen. Using the control assembly and a configuration screen you can easily define the following well test properties: Point Scheme, data retention value, relative facilities, UDCs, headers, wells in the well test, header templates, positions, commands, and associated actions for each command.

See Configuring Well Test Using Canvas for more information.

Configuration Headers

The well test configuration XML contains the following important elements:

• Header Point — The well test configuration XML contains a list of headers and their associated wells that will be included in the well test sequence.
• Header Point Queue — The queue is an XML string that is written to the Header point (as PNT HyperPoint Script Text). There are multiple header queues, one for each header, and each can be modified in many ways (i.e. screens, MSS, external interface such as ForeSite, etc.). A SetPoint command is issued to the Header Point to tell the queue to do the work. For example, a value of "Start" will start the well test process on the specific header/test facility. The first enabled well in the queue is taken off, passed into the workflow, and processed according to the configuration. After that well is finished, the next enabled well in the queue is taken off the queue and processed. Other values can be set to control the processing of the queue (Start, Stop, Continuous, Clear, Complete, Abort, etc.) as the well test process unfolds.

Well Test Configuration XML

The Well Test Configuration XML defines the logical blocks required to perform well test actions. It includes header points, which define the associated wells to be included in the well test sequence, and the relationship of wells to the valves in various positions, and a header queue to monitor multiple headers. The well test configuration is an XML string that is manually written to a configuration point in the PNT as HyperPoint script text.

See Configuring Well Test Using XML for more information.

VBScript to Process Well Test Results

Once the well test action sequence completes, the well test contents must be generated. Since the values for the well test record can come from various locations due to the unique configurations at the field-level, a programmable approach in the form of a VBScript is required.

A sample script is available to illustrate the concept of processing supplied arguments and providing the necessary output that the CygNet Well Test module expects in order to process a well test record. The VBScript will need to be customized for the user's environment.

See Processing and Storing Well Test Results for more information.

Well Test Record Storage

Well test records are stored as XML strings in VHS entries for each configured well. After the VBScript engine exits processing, the well test data is complete, and the appropriate output is available, the CygNet Well Test module will create the well test configuration XML record (an XML string) and store it as a VHS Blob entry in the appropriate VHS point. External systems can also consume the well test records stored in the VHS using the CygNet.API.WellTest API.

See Processing and Storing Well Test Results and Retrieving Well Test Records for more information.

Well Test Canvas Screens for HMI

CygNet Well Test module uses Canvas screens to visualize well test status and detail information. The screens can also be used to initiate an on-demand well test campaign. The sample Canvas screens are included in the Samples\Well Test folder. The screens will need to be customized for the user’s environment.

See Sample Well Test Screens and Scripts for more information.